Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/inet/ietf/cipso/cipso-minutes-91jul.txt

Text File | 1993-02-17 | 10.2 KB | 315 lines

CURRENT_MEETING_REPORT_



Reported by Ron Sharp/AT&T

CIPSO Minutes

Here are the Minutes for the Commercial Internet Protocol Security
Option Working Group meeting held in Atlanta, Georgia.  Most of these
Minutes were provided by Noel Nazario who recorded them and sent me an
electronic version.  Thanks again Noel.  The Working Group met for 1.5
days with the first half day being spent on new issues described below.
The second day we addressed and closed nearly all of the old issues.

Quick CIPSO Summary

Option type 134.  One option per packet.  Only sensitivity tags are
currently defined in the document.  The document provides a common
format and minimum configuration parameters required for
interoperability.  Interpretation of values within the option are
DOI-dependent (Domain of Interpretation).


Description of Open Issues


  1. Clarifications to the Spec
  2. Multiple DOI's
  3. Sort Categories
  4. Policy on unrecognized tags
  5. Exclusionary tag types
  6. Multiple sensitivity tags
  7. Minimum RFC Compliance
  8. Tag alignment
  9. Change exclusionary tag type number
 10. Error condition definition
 11. Configuration parameters
 12. New tag types
 13. Tags 128-255, Vendor/DOI defined
 14. Move security level out of tags
 15. Vendor tag types - router problem
 16. 8-bit security level and 2-bit errors
 17. Header space
 18. Should DOI  #3 be included in spec for testing
 19. Canonicalization of encodings
 20. Whether to allow category 0
 21. Routing based on nationality caveats


New issues

Mike St.  Johns proposed the following change to the CIPSO format:

                                   1






         8         8             16 bit
   |--------------------------------------------|
   |  Type    | Length  |        Level          |
   |--------------------------------------------|
   |                  DOI                      |
   |--------------------------------------------|
   |  Cat ID  |           Categories            |
   |--------------------------------------------|
   | (8 bits) |            (24 bits)            |
   |--------------------------------------------|
   |   255    |                                |  <-- Sys Hi
   |--------------------------------------------|



This format will effectively eliminate all tags.  Its basic merit is
that it is simpler for routers to handle.  The 16-bit security level is
to be encoded for certain Hamming distance and not open to definition of
2 to the 16th levels.  It would be easy for a router to implement.  No
flexibility in specifying different security policies.

It was voted 9:4 to continue the discussion of the other issues and
table this proposal and discuss it more electronically before the next
meeting.

Discuss and Close Issues


   o Issue 1:  Spec Clarifications

     Section 4, eliminate the non-security IP options from the document.
     This section will be replaced with a reference to the Internet
     Assigned Numbers Administration (IANA).

     Note that the length fields and tag numbers in the document should
     be reviewed and corrected.

     The requirement to transmit between DOI should be done by IP
     gateways and not by routers.  Pro:  11, Con:0

     Clarify the concept of classes of tags (i.e., sensitivity tags).
     Pro:  12, Con:  0.

   o Issue 3:  Sort Categories

     Categories enumerated in type-2 tags should appear in ascending
     order.  Pro:  12, Con:  0

   o Issue 5:  Exclusionary tag type change

     Eliminate the exclusionary flag from the enumerated tag in favor of

                                   2





  adding a new range tag type with lower and upper bounds.  Pro:  14,
  Con:  0

  Redesigning Tag Type 2

            8          8          8
       |----------------------------------------------------------|
       |   Type   |  Length  |   Level   |  Enumerated Categories |
       |----------------------------------------------------------|

       It was voted to eliminate the flags field from the Tag Type
       2 format.  Pro: 13, Con: 1

       Design Tag Type 5  (Range type)

            8      8      8     16   16
       |------------------------------------------------------|
       | Type= 5 | Len | Level | 1h | 1l |   |...|  | nh | nl |
       |------------------------------------------------------|
                                                          ^
                                                 Optional, 0
                                                  assumed if
                                                     missing


  nh is the range high value and nl is the range low value.  ranges
  are sorted high to low non-overlapping.

  The use of this format for the new Tag Type 5 was voted Pro:11,
  Con:  2.

o Issue 8:  Tag alignment

  Compliant implementations will support unaligned tags.  Pro:  12,
  Con:  0

o Issue 13:  Tag types 128-255:  Vendor/DOI assigned

  It was agreed that these tag types would be defined by the DOI and
  not the vendor.  For example, a vendor should not implement a new
  tag format with a hard coded type number >127 unless the
  implementation is solely for a particular DOI.

  The need of these tag types was questioned during the meeting.
  There was concern that allowing users to define their own label
  formats could lead to non-interoperability issues later.  It was
  decided to table the discussion until we had more time to look at
  the problem.

o Issue 2:  Multiple DOI's

  2a.  Implementations must support one DOI and may/should support

                                3





     more than one.  Pro:  13, Con:  0

     2b.  Recommend to administrators that a common DOI should be
     understood by all hosts on a subnetwork.  Pro:  12, Con 0

     2c.  For outgoing communications the DOI is selected based on
     either the network interface that will be used or by the address of
     the destination.  This insures that the DOI selected on outgoing
     packets is not just a host level default but can be configured
     based on either the network interface (i.e., network default DOI)
     or by the destination host address.  If it is on the destination
     host address then a DOI could be configured for the destination IP
     subnetwork or the host itself.  Pro:  8, Con:  0

   o Issue 18:  Reserve DOI number 3 for use in testing

     Not necessary to include in the RFC. DOI's are configurable.  Pro:
     12, Con:0

   o Issue 6:  Multiple sensitivity tags

     Only one sensitivity tag included in a CIPSO option.  Pro:  8, Con:
     2.

   o Issue 19:  Canonicalization

     Require a common deterministic algorithm in CIPSO implementations
     where each label can be represented by only 1 sensitivity tag type.


      -  Increases speed of equality check
      -  Possible algorithms
          * Ascending order of tag numbers (1 first then 2 .  .  .)
          * Minimize space (use tag that requires least bytes)
      -  Possible loss in speed due to time required for new algorithm
      -  Goes against concept of maximize what you will accept


     Tabled

   o Issue 4:  What to do on unrecognized tag types

     The behavior on unrecognized tag types should be configurable with
     the default being not to accept the packet.  Pro:  8, Con:  4.

     Make configuration optional, the default being to generate an error
     on unrecognized tags.  Pro:  10, Con:  1


Issues not discussed due to time constraints


                                   4





  1. Minimum RFC compliance

  2. Error conditions and responses.  Brian Yasaki and Debbie Futcher
     wrote up a section for error conditions.  A new copy will be sent
     out the mailing list and comments should be placed back on the
     mailing list.

  3. Configuration parameters.  Minimal configuration parameters
     required for each CIPSO host.  Some of these changed with the
     issues discussed and a new version will be put on the mailing list
     before the next meeting.



Conclusion

As you can see we made it through a lot of issues and closed most of
them.  This is great.  Part of the reason many were closed so quickly is
that we discussed them at the previous CIPSO IETF meeting but we agreed
to hold them open until this meeting.

A request was made for a new CIPSO IETF editor.  Mark Powers has been
doing a great job but due to job requirements he has not been able to
make many of the meetings.  Mark Christenson from Cray volunteered to do
the work.  I will make the appropriate changes to the document and
submit it to Internet-Drafts and then give the document to Mark.  Thanks
Mark.

The next meeting of the CIPSO IETF will be at the HP complex in
Cupertino, CA September 24th - 26th of this year.  It will be held in
conjunction with the TSIG meeting.  It will start around 9am on the 24th
and will have a morning wrap-up on the 26th ending around noon.  I will
send out more details as I get them.

If you have comments on any of the issues discussed please put these
comments out on this mailing list now.  Do not wait until the next
meeting.  If you have any new issues then again please bring them out
now.  New issues brought up at the next meeting will take a lower
priority to existing issues that have had a chance to be digested and
discussed on the mailing list.

Attendees

Richard Balcon           [e-mail]
Tom Benkart              [e-mail]
Nelson Bolyard           [e-mail]
Doug Brown               [e-mail]
Mark Christenson         [e-mail]
Daylan Darby             daylan@ssc_bee.boeing.com
Deborah Futcher          [e-mail]
Amir Hudda               [e-mail]
Barry Miracle            [e-mail]
Noel Nazario             [e-mail]

                                   5





Oscar Newkerk            [e-mail]
Jackie Proveaux          [e-mail]
John Seligson            [e-mail]
Ron Sharp                [e-mail]
Rick Slade               [e-mail]
Richard Smith            [e-mail]
Frank Solensky           [e-mail]
Michael St.  Johns       [e-mail]
Emil Sturniolo           [e-mail]
Bruce Taber              [e-mail]
Dean Throop              [e-mail]
Gerard White             [e-mail]
Brian Yasaki             [e-mail]



                                   6